The evolution of computers and networking technologies from high-cost, low-performance data processing systems to low-cost, high-performance communication, problem solving and entertainment systems has provided a cost-effective and time saving means to lessen the burden of performing every day tasks such as correspondence, bill paying, shopping, budgeting and information gathering. For example, a computing system interfaced to the Internet via wire or wireless technology, can provide a user with a channel for nearly instantaneous access to a wealth of information from a repository of web sites and servers located around the world, at the user's fingertips.
Typically for such systems, application developers, unless instructed otherwise, tend to write stateful applications that retain information necessary for correct and successful execution across interaction and transaction boundaries. Such stateful applications risk losing state when the system on which they execute crash. For example, such a crash can create a “semantic mess” that may require human intervention to repair or restart the application, resulting in long service outages. The classic response has been to insist that an application be “stateless”, where stateless means “no meaningful information is retained across transactions”. Nonetheless, such stateless applications force a rather unnatural form of workflow programming. Often for a stateless application step within a transaction, the application step should first read its state from a transactional queue, execute its logic, and then commit the step by writing its state back to a queue for the next step. Such a programming model also has a potential performance problem due to the need for two phase commit.
Likewise, middle tier applications commonly employ stateless applications. In general, an enterprise middle tier application is typically made up of one or more server components that implement business logic and expose a set of interfaces. A handful of the components in the application may access persistent data, typically stored in a relational database. Also, many components perform a specific task (calculation, data formatting, and the like) on behalf of server components, possibly modifying data and returning a result, yet they retain no state. In addition, there are a small number of critical components that maintain state for the application during the session.
A classic example for a middle tier application is a middle tier e-commerce system for shopping and price comparison. In general, a client session begins when a customer logs in, and customer information is read from a database into a component. As the customer shops, purchases are recorded in the stateful component representing the market basket. When the customer checks out, items in the basket are written to databases (e.g., orders and billing) and the customer database is updated to reflect recent activity.
If a failure occurs during the session, all volatile state can be lost and the session must typically be restarted. Such can result in lost revenues and frustrated customers. Also, depending on the application and point of failure, updates may have to be manually backed out to restore consistency to the system. To avoid this, middle tier systems have typically been designed as stateless applications. Yet, the unnatural programming style associated with stateless applications increases development costs and may reduce system throughput.
At the same time, enterprise applications need to be highly available and scalable. In the past, this has required “stateless” applications, which essentially require the application to manage its state explicitly by storing it in transactional resource managers. Despite “stateful” applications being more natural and hence easier to write with less error, having the system manage this state automatically has been considered too difficult and too costly.
Accordingly, a system builder is faced with a dilemma and has to choose between either: fast and easy development (resulting in applications that are more likely to be correct applications, implemented in a natural stateful programming style, but which fail to provide availability and scalability), or the high availability and scalability of the stateless programming model (which adds to development time and where correctness is more difficult to achieve because of the intrusion of additional concerns of explicit state management.)
Therefore, there is a need to overcome the aforementioned exemplary deficiencies associated with conventional systems and devices.